Fix Issue #173 - Fix Bow Sustained Firing#174
Open
crkellen wants to merge 9 commits intoTurningWheel:barony-nextfrom
Open
Fix Issue #173 - Fix Bow Sustained Firing#174crkellen wants to merge 9 commits intoTurningWheel:barony-nextfrom
crkellen wants to merge 9 commits intoTurningWheel:barony-nextfrom
Conversation
added 9 commits
August 13, 2017 18:31
Update to Latest Code
+ 5 blank spellbooks.
Barony next update to latest
Barony next update to latest
Collaborator
|
May need review with #86 in mind. |
lheckemann
reviewed
Oct 20, 2017
| players[clientnum]->entity->attack(0, 0, nullptr); | ||
| HUDWEAPON_MOVEX = 3; | ||
| throwGimpTimer = TICKS_PER_SECOND / 4; | ||
| throwGimpTimer = 12; // Was TICKS_PER_SECOND / 4 |
Contributor
There was a problem hiding this comment.
Any particular reason for this change? Having it defined as "a quarter of a second" seems better than having it defined as "12 ticks", which would change firing behaviour if the tick rate is changed.
Contributor
|
Should be fine, I think. |
Contributor
Author
|
I believe the reason for the change was because every frame it would be calculating the exact same value, as the framerate couldn't change (#define'd). I can revert it later today.
null
|
Contributor
Author
|
It could cause issues, but it shouldn't, since the actual issue is that the pointer is never cleared, allowing for loads of undefined behavior to be possible.
FMOD seems to either handle those issues on their end, or doesn't care about them.
null
|
Contributor
The compiler can work that out just fine, don't worry about it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a fix for #173.
The issue is that with OpenAL, undefined behavior can happen which is not present with FMOD. This undefined behavior is the program believing that the clip is still playing, or has started, despite it only playing once. Likely, this is not an issue with OpenAL, but rather, the game code is intertwined with the sound code, and the pointer is never cleared, which allows a previously ended sound clip to continue to exist until the next time it is assigned.
Pointers should not be kept alive to old objects. Undefined behavior is happening because until the bow is fired again, this pointer continues to exist with it's old data, and continues to try and process 'OPENAL_Channel_IsPlaying()'
Likely, this will not cause any issues with FMOD, and will actually be better. You feel free to test and correct me if I am wrong.